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By  enabling  the  use  of  WebDAV  in  MYSEA,  this  thesis  provides  a  means  for 
fulfilling  the  above  requirement  for  secure  remote  access  by  creating  a  virtual  web-based 
file  system  accessible  from  the  MYSEA  MLS  network.  This  is  accomplished  by 
incorporating  the  moddav  module  into  the  Apache  web  server  already  installed  on  the 
MYSEA  server.  The  use  of  a  module  required  minimal  changes  to  add  the  desired 
functionality.  Integration  of  mod  dav  is  performed  in  three  stages  to  aid  in  tracing  the 
source  of  any  errors.  Functional  and  security  testing  is  also  performed,  ensuring  that  the 
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I.  INTRODUCTION 


A.  MOTIVATION 

The  balance  between  providing  access  to  data  for  those  who  need  it,  and 
protecting  that  same  data  from  unauthorized  access  is  a  difficult  problem  as  well  as  a 
major  concern  for  project  managers  who  must  deal  with  classified  infonnation. 
Multilevel  Secure  (MLS)  systems  provide  a  great  deal  of  access  restriction  and, 
hopefully,  assurance  that  only  those  who  have  authorization  to  access  the  data  can  do  so. 
However,  with  this  security  often  comes  the  sacrifice  of  usability,  much  to  the  chagrin  of 
users  and  administrators  alike.  Unfortunately,  it  has  thus  far  proved  too  difficult  to 
provide  both  an  adequate  assurance  of  security  as  well  as  a  user-friendly  environment  in 
one  operating  system. 

By  using  a  more  user-friendly  operating  system  to  remotely  access  data  located  on 
the  machine  controlled  by  the  more  secure  MLS  operating  system,  it  is  possible  to 
provide  users  with  access  to  the  functions  that  are  restricted  by  the  MLS  server  but  are 
helpful  for  productivity.  Security  can  also  be  maintained  in  this  situation  if  measures  are 
taken  to  ensure  that  unauthorized  downgrading  of  information  is  prevented.  These 
features  are  planned  for  the  MYSEA  client  machines. 

The  motivation  for  this  study  is  to  use  WebDAV  to  facilitate  more  flexible  access 
to  sensitive  data  in  the  MYSEA  environment  while  maintaining  the  security  of  the  MLS 
constraints. 

B.  PURPOSE 

The  objective  of  this  project  is  to  utilize  the  moddav  Apache  module  in  the 
existing  installation  of  Apache  on  the  MYSEA  server  to  provide  remote  users  on  the 
MLS  network  a  virtual  file  system  with  access  to  both  private  and  public  data  stored  on 
the  MYSEA  server. 

C.  ORGANIZATION  OF  PAPER 

This  thesis  is  organized  as  follows: 

•  Chapter  I  provides  an  introduction  to  the  motivation  and  purpose  of  this 
thesis. 
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•  Chapter  II  provides  background  information  on  WebDAV,  the  moddav 
Apache  module  and  the  MYSEA  project. 

•  Chapter  III  describes  the  goals  of  the  thesis,  the  concept  of  operation  and 
the  steps  taken  to  complete  the  goal. 

•  Chapter  IV  describes  the  test  plans  used  to  validate  each  implementation 
phase  of  this  thesis. 

•  Chapter  V  concludes  with  a  project  summary,  a  discussion  or  related  work 
and  suggestions  for  future  work. 
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II.  BACKGROUND 


This  chapter  provides  background  information  on  various  subjects  related  to  the 
integration  of  WebDAV  into  the  MYSEA  MLS  environment.  The  first  section  covers  the 
WebDAV  protocol  extensions  and  uses  as  well  as  a  specific  implementation  of  the 
protocol  while  the  second  section  introduces  the  MYSEA  project. 

A.  WEBDAV 

Web-based  Distributed  Authoring  and  Versioning  (WebDAV)  is  a  set  of 
extensions  to  the  Hypertext  Transfer  Protocol  (HTTP).  It  is  described  in  RFC  2518  [1] 
and  developed  by  an  Internet  Engineering  Task  Force  (IETF)  working  group  that  is 
aimed  at  allowing  users  to  collaboratively  edit  and  manage  files  on  a  remote  web  server. 
The  goals  of  the  WebDAV  working  group,  as  stated  in  their  charter,  are  to  "define  the 
HTTP  extensions  necessary  to  enable  distributed  web  authoring  tools  to  be  broadly 
interoperable,  while  supporting  user  needs."  [2]  In  essence,  WebDAV  provides  the 
capability  to  not  only  read  static  objects  over  a  network,  but  to  perform  more  interactive 
operations  as  well.  The  operations,  or  methods,  included  in  WebDAV  and  a  description 
of  their  functions  can  be  referenced  in  Table  1. 


Method 

Description 

PROPFIND 

This  method  is  used  to  retrieve  the  properties  of  a  resource  from  the  server. 

PROPPATCH 

This  method  is  used  to  set  the  properties  of  a  resource  and  propagate  them  to  the  server. 

MKCOL 

This  method  is  used  to  create  a  new  directory,  known  here  as  a  collection. 

GET 

Essentially  the  same  as  the  HTTP  GET  method,  but  extended  for  use  with  collections. 

HEAD 

Essentially  the  same  as  the  HTTP  HEAD  method,  but  extended  for  use  with  collections. 

POST 

Same  as  the  HTTP  POST  method.  Includes  all  resources  except  for  collections. 

DELETE 

This  method  deletes  a  resource,  including  collections. 

PUT 

Creates  a  new  (non-collection)  resource,  or  replaces  and  existing  one,  with  data  sent  to  the  server. 

COPY 

Creates  a  duplicate  of  the  target  resource,  including  collections. 

MOVE 

Moves  the  target  resource  from  its  original  location  to  a  new  location,  including  collections. 

LOCK 

Makes  the  specified  property  of  a  resource  unable  to  be  changed,  including  collections. 

UNLOCK 

Allows  the  specified  property  of  a  resource  to  be  changed,  including  collections. 

Table  1.  WebDAV  Methods 
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WebDAV  Client 


Legend: 


I  Apache  filesystem 


WebDAV  filesystem 


Figure  1.  WebDAV  Client-Server  Architecture 

Resources,  collections  and  properties  are  the  three  major  components  of  a 
WebDAV  file  system.  Resources  are  any  type  of  file,  including  collections.  Collections 
are  simply  another  word  for  directories.  Properties  are,  to  quote  the  RFC,  “Properties  are 
pieces  of  data  that  describe  the  state  of  a  resource.  Properties  are  data  about  data.”  [1]  For 
example,  properties  can  contain  basic  information,  such  as  subject  and  author,  about  a 
given  resource.  Properties  are  embodied  through  the  use  of  specialized  XML  tags  and  can 
be  controlled  by  both  the  server  and  the  client. 

1.  WebDAV  File  System 

An  obvious  use  of  these  methods  is  to  support  a  file  system  accessible  from 
remote  clients,  as  is  shown  in  Figure  1.  WebDAV  enabled  access  to  this  file  system 
would  allow  users  to  create,  modify  and  share  resources,  within  the  specified  WebDAV 
directory,  remotely  over  a  network.  This  would  allow  for  both  private  file  storage  and 
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collaborative  file  repositories.  The  root  directory  of  a  WebDAV  directory  tree  can 
coincide  with  an  existing  directory  subtree,  or  can  be  isolated  to  its  own  section  of  the 
existing  file  system. 

2.  moddav  Apache  Module 

The  WebDAV  module  for  the  Apache  Webserver  (named  mod  dav)  is  one  of  the 
most  common  server-side  implementations  of  the  WebDAV  protocol  and  is  the 
implementation  used  in  this  thesis.  Apache  uses  mod  dav  to  extend  its  capabilities  to 
include  those  specified  by  the  WebDAV  protocol.  The  mod  dav  module  allows  access  to 
individual  subtrees  to  be  controlled  on  a  per  user  basis  with  an  access  control  list  (ACL) 
determined  in  advance  by  the  administrator  via  the  standard  configuration  file.  [3] 


B.  MYSEA 

The  Monterey  Security  Architecture  (MYSEA)  project  is  aimed  at  developing  a 
secure  architecture  that  will  allow  services  and  data  from  various  networks  of  differing 
classification  levels  to  be  aggregated  into  a  single,  multilevel  network.  This  is 
accomplished  using  commercial-off-the-shelf  (COTS)  components  for  performing  most 
applications  along  with  secure  high  assurance  components  that  enforce  the  security 
policies.  The  use  of  COTS  resources  is  desirable  since  COTS  products  are  usually  less 
expensive,  more  easily  obtained  and  already  in  more  widespread  use  than  custom 
proprietary  hardware  and  software.  Unfortunately,  COTS  products  rarely  have  adequate 
assurance  that  the  policy  they  are  designed  to  enforce  will  be  done  so  sufficiently.  This 
problem  is  solved  in  MYSEA  through  the  incorporation  of  high  assurance  components. 
Thus  in  MYSEA,  security  is  still  enforceable  across  various  sensitivity  levels  without 
needing  to  have  physically  separate  hardware  for  each  level  of  security.  MYSEA  relies 
on  a  high  assurance  platform  that  provides  an  adequate  degree  of  certainty  that  the  MLS 
policies  will  be  enforced.  MYSEA  is  aimed  at  achieving  a  higher  adoption  rate  than 
previous  MLS  systems  in  organizations  that  already  own  a  large  number  of  COTS 
resources  and  do  not  wish  to  incur  the  cost  of  replacing  the  hardware  and  training  (or 
retraining)  their  users  on  the  new  systems.  [4]  [5] 

Figure  2  is  an  illustration  of  the  MYSEA  network  architecture.  Communication 

between  an  untrusted  client  on  the  MLS  LAN  and  various  application  services  on  either 
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the  server  or  any  of  the  connected  networks  is  handled  by  an  XTS-400  high  assurance 
MLS  server.  This  MLS  server  allows  communication  only  at  or  below  the  currently 
negotiated  session  level.  The  security  level  of  each  session  is  negotiated  with  the  MLS 
server  via  a  Trusted  Path  Extension  (TPE)  that  resides  inline  between  the  client  and  the 
server  and  establishes  a  trusted  path,  which  may  be  encrypted,  to  the  MLS  server. 

Currently,  the  MYSEA  server  supports  HTTP,  SMTP  and  IMAP.  Tarantella  (a 
web-portal  for  remotely  running  graphical  applications,  similar  to  X  or  Citrix),  which 
executes  on  servers  located  on  attached  single  level  networks,  is  also  available.  These 
services  allow  for  a  wide  variety  of  common  applications  to  be  used,  but  there  is  one 
major  component  lacking:  the  ability  to  remotely  access  and  modify  files  in  an  MLS 
context.  The  goal  of  this  thesis  is  to  fill  the  gap  by  providing  such  a  service  through  the 
use  of  WebDAV  via  a  module  extension  to  the  existing  Apache  web  server  within  the 
trusted,  high  assurance  MYSEA  server. 
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Figure  2.  Testbed  Topology  [From  Ref.  4] 
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C.  SUMMARY 

This  chapter  provided  an  introduction  to  WebDAV,  gave  brief  background 
information  on  the  MYSEA  project  and  its  related  components  and  discussed  why  this 
thesis  is  needed.  The  next  chapter  will  discuss  the  strategies  used  to  get  WebDAV 
running  in  different  modes  of  operation  on  both  Linux  and  the  MYSEA  server. 
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III.  PROJECT  DESCRIPTION 


This  chapter  will  state  the  project  goals,  explain  the  concept  of  operation,  describe 
the  details  of  the  hierarchical  file  system  design  and  describe  the  porting  methodology. 
The  problems  encountered  during  installation,  as  well  as  the  steps  taken  to  solve  them, 
will  be  discussed  along  with  the  methodology. 


A.  GOALS 

The  goal  of  this  thesis  is  to  utilize  WebDAV  in  the  MYSEA  multilevel 
environment  to  provide  users  on  the  MLS  network  with  remote  access  to  data  whose 
security  classification  is  dominated  by  the  security  level  of  the  currently  authorized 
session.  Access  to  files  is  mediated  by  both  the  MAC  and  DAC  policies  of  the  server. 
WebDAV  provides  facilities  for  reading,  writing  and  locking  files,  which  can  be  useful 
for  implementing  a  virtual  network  file  system  consisting  of  both  a  public  file  repository 
and  private  data  stores.  Ultimately,  the  use  of  WebDAV  allows  users  with  a  WebDAV 
client  to  access  data  on  the  MYSEA  server  remotely,  possibly  in  a  similar  manner  to 
mounting  and  accessing  data  with  a  standard  network  drive.  (Detailed  instructions  for 
using  various  clients  to  access  a  WebDAV  directory  can  be  found  in  Appendix  A.)  This 
provides  a  facility  for  data  to  be  conveniently  and  securely  accessed  remotely  in  the 
MYSEA  environment.  Currently  access  to  data  on  a  MYSEA  server  is  restricted  to  either 
browsing  static  web  pages  or  through  various  CGI  scripts  that  allow  limited  operations 
[6].  This  project  is  intended  to  fill  the  need  for  more  flexible  access  to  data.  A  further 
requirement  is  that  the  client  be  able  to  “read  down”  to  data  at  a  lower  security  level  to 
take  advantage  of  the  MLS  capabilities  offered  by  the  server  as  well  as  to  facilitate 
effective  use  by  the  MYSEA  clients  planned  for  the  future  [4]  [5]. 


B.  CONCEPT  OF  OPERATION 

In  the  MYSEA  MLS  network  environment  it  is  necessary  for  a  client  to 
authenticate  to  the  MYSEA  server  before  connecting  to  any  service.  Authentication  can 
be  achieved  using  either  a  TPE  (Trusted  Path  Extension)  device  or  the  cross  platform 
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TCBE  (Trusted  Computing  Base  Extension)  Java  client.  With  either  of  these  methods  a 
user  can  authenticate  himself  to  the  server  and  negotiate  a  session  at  a  security  level  for 
which  the  user  is  authorized.  The  level  of  the  negotiated  session  determines  what  level  of 
access  the  user  will  have  with  any  of  the  services  on  the  MYSEA  server,  including 
WebDAV.  This,  along  with  the  binding  between  a  user’s  ID  and  subjects  executing  on 
his  behalf,  allows  the  underlying  STOP  6.1  operating  system  to  be  used  to  enforce  both 
MAC  and  DAC  security  policies. 

Once  the  user  is  logged  in  and  the  session  level  is  selected,  a  WebDAV  client  may 
be  used  to  access  fdes  and  perform  operations  (such  as  read,  write,  lock  and  unlock) 
available  via  the  WebDAV  server.  Instructions  for  using  various  WebDAV  clients  can  be 
found  in  Appendix  A. 

Once  connected  to  the  MYSEA  WebDAV  server,  a  user  can  access  both  private 
and  public  data  at  a  level  equal  to  or  below  the  current  session  level.  Whereas  the  private 
directories  are  available  only  to  the  user  that  owns  them,  the  public  directories  are 
accessible  by  any  user  able  to  establish  a  session  at  the  appropriate  security  level.  The 
only  other  restriction  is  that  files  that  are  locked  by  a  user  cannot  be  overwritten  or 
modified  in  any  way  until  the  lock  is  released. 

The  following  two  example  scenarios  illustrate  possible  collaboration  between 
two  users  via  WebDAV  in  a  multilevel  environment. 

Scenario  1 :  Alice  and  Bob  are  logged  in  at  the  same  security  level.  They  can  both 
simultaneously  edit  multiple  files  in  the  WebDAV  directory,  both  in  the  public  area  and 
their  own  private  directories.  Alice  decides  she  wants  to  edit  the  file  “readme.txt”  in  the 
public  directory,  so  she  first  locks  the  file  to  make  sure  that  Bob  cannot  modify  the  same 
file  while  she  is  working  on  it.  When  Bob  tries  to  edit  “readme.txt”,  he  will  be  able  to 
open  the  file,  but  will  be  unable  to  save  any  changes  because  of  the  lock.  However,  Bob 
can  save  his  edited  copy  of  “readme.txt”  to  his  private  directory  so  that  he  can  come  back 
later  to  save  his  changes. 

Scenario  2:  Alice  and  Bob  are  logged  in  at  different  security  levels;  with  Bob’s 
level  dominating  Alice’s.  Alice  still  edits  the  “readme.txt”  file,  which  is  at  the  same  level 
as  Alice’s  established  session  level,  but  this  time  she  forgets  to  lock  it  first.  Bob  can  still 
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open  up,  read  and  edit  “readme.txt”,  but  he  cannot  save  the  changes  since  he  is  not 
allowed  to  write  information  down  to  a  lower  level,  as  per  the  MAC  policy.  However, 
when  Bob  saves  his  edited  version  of  “readme.txt”,  this  time  it  will  be  saved  at  Bob’s 
session  level. 


Although  the  process  of  connecting  to  and  using  WebDAV  resources  from  a 
remote  client  is  fairly  simple,  the  exact  steps  differ  from  one  client  to  another.  Most 
major  operating  systems  include  support  for  connecting  to  and  working  with  WebDAV 
servers  by  default.  In  most  cases,  the  process  of  connecting  to  a  WebDAV  server  is  very 
similar,  if  not  identical,  to  connecting  to  and  mounting  a  network  drive.  There  is  also  a 
third  party  application  called  Cadaver  [7]  that  runs  on  any  UNIX  based  operating  system. 
Cadaver  acts  like  most  command  line  FTP  clients  and  allows  for  the  use  of  a  wider  range 
of  WebDAV  functions  (such  as  file  locking)  as  compared  to  the  graphical  clients  (i.e.  the 
clients  accessible  through  a  GUI).  Instructions  for  using  built-in  WebDAV  clients  (for 
Windows,  Fedora  Core  4  and  Macintosh)  as  well  as  for  using  Cadaver  are  provided  in 
Appendix  A. 


Figure  3.  MYSEA  Network  Topology 
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The  Apache  server  that  is  currently  installed  and  configured  on  the  MYSEA 
server  is  only  accessible  from  the  MLS  network  and  not  from  any  of  the  single  level 
networks  connected  to  the  MYSEA  server.  It  would  be  possible  to  set  up  an  Apache 
server  with  WebDAV  for  each  of  the  single  level  networks  to  allow  access  to  the  same 
set  of  data  as  is  available  to  the  MLS  network.  Since  users  accessing  from  a  single  level 
network  cannot  change  their  session  level  via  a  TPE  or  TCBE,  access  would  be  less 
flexible  than  from  the  MLS  network  since  users  on  a  single  level  network  are  restricted  to 
the  security  level  that  network  is  bound  to.  A  user  on  a  single  level  network  would  still  be 
able  to  read  down  to  data  at  a  lower  security  level,  but  would  be  unable  to  read  anything 
higher  or  write  anything  other  than  at  the  level  he  or  she  is  bound  to,  even  though  the  user 
may  be  cleared  for  access  to  more  sensitive  infonnation.  See  Figure  3  for  an  illustration 
of  the  network  topology. 


C.  DESIGN 

Currently,  the  file  system  on  the  XTS-400  is  set  up  to  keep  most  of  the  MYSEA- 
related  applications  (including  the  Apache  httpd  binary),  configuration  files  and  data  in 
one  directory,  specifically  “/usr/local/mysea/”1.  However,  Apache  has  been  configured  in 
MYSEA  to  use  “/home/http/”,  the  home  directory  of  the  http  user,  to  store  its  various 
configuration  files  and  data,  while  “/usr/local/mysea/apache/”  contains  the  executable 
binary  and  related  source  code.  The  main  configuration  file  is  named  and  located  at 
“/home/http/conf/httpd.conf’  and  the  Document  Root  is  located  at  “/home/http/htdocs/”. 
The  Document  Root,  by  definition,  contains  all  of  the  files  that  can  be  served  by  (i.e. 
accessed  remotely  through)  the  Apache  server. 

To  add  WebDAV  support  to  the  existing  Apache  server,  a  new  directory, 
“/home/http/htdocs/dav/”,  was  added  to  the  Document  Root.  For  the  central  public 
WebDAV  directory,  a  new  directory,  “/home/http/htdocs/dav/public/”,  was  created.  To 
allow  individual  users  to  have  a  private  data  store  available  via  WebDAV,  a  new 
directory,  “/home/http/htdocs/dav/private/”,  was  added  to  contain  a  symbolic  link  to  each 

1  This  and  all  directory  paths  given  in  this  chapter  are  absolute  (with  respect  to  the  root  of  the  file 
system)  rather  than  relative.  All  directories  referenced  are  at  secrecy  level  0  and  integrity  level  3  unless 
otherwise  noted. 
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user’s  home  directory.  The  Apache  configuration  was  then  altered  (as  per  the  instructions 
in  Appendix  A)  to  allow  WebDAV  to  be  used  in  the  “/home/http/htdocs/dav/”  directory. 
This  also  allows  all  subdirectories  of  this  directory,  the  root  DAV  directory,  to  be 
accessed  with  WebDAV.  See  Figure  4  for  an  illustration  of  the  changes  made  to  the  file 
system. 

For  each  directory  in  the  XTS-400  file  system  that  is  set  up  for  WebDAV  use, 
both  in  the  public  and  private  sections,  various  subdirectories  need  to  be  created  for  each 
combination  of  secrecy  and  integrity  levels  that  need  to  be  accessed.  These  different 
single  level  directories  need  to  be  created  administratively  and  cannot  be  added  by  the 
user  via  WebDAV.  An  alternative,  simpler  way  to  implement  a  similar  scheme  would  be 
to  use  a  deflection  directory.  However,  associated  with  the  deflection  directory  method 
are  the  undesirable  consequences  described  below. 
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Before 


After 


Figure  4.  File  System  Before  and  After 


A  deflection  directory  is,  in  essence,  a  directory  that  exists  independently  at  all 
security  levels  simultaneously.  In  the  deflection  model,  when  a  directory  is  accessed  an 
instance  of  the  directory  corresponding  to  the  current  security  level  is  automatically 
chosen  by  the  OS.  There  is  no  possibility  of  accessing  a  deflection  directory  at  a  level 
other  than  the  level  of  the  current  session,  and  no  data  is  shared  between  different 
instances.  This  ensures  that  no  data  can  be  read  from  a  higher  security  level  or  written  to 
a  lower  security  level.  However,  the  use  of  deflection  directories  also  prevents  data  from 
being  read  from  a  security  level  lower  than  that  of  the  current  session.  Since  it  is  a 
MYSEA  requirement  that  users  can  read  data  at  a  lower  security  level,  this  arrangement 
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was  deemed  unacceptable.  This  requirement  led  to  the  conclusion  that  using  separate 
directories  for  each  security  level  was  a  more  desirable  design  than  that  of  using  a  single 
deflection  directory. 

To  keep  the  personal  WebDAV  directories  private,  their  DAC  properties  were  set 
to  allow  only  the  owner  to  have  read  and  write  access  to  these  directories.  Each  user  also 
needs  to  have  an  individual  directory  for  each  security  level  accessed.  Since  the  user 
cannot  create  these  directories  at  the  required  security  levels  over  the  WebDAV 
connection,  it  is  necessary  for  the  administrator  to  create,  at  the  minimum,  a  select  few 
directories  at  commonly  used  security  levels  at  the  time  the  user  account  is  created. 


D.  METHODOLOGY 

While  it  would  have  been  possible  to  begin  by  implementing  WebDAV  in  the 
multilevel  MYSEA  environment,  as  was  ultimately  the  goal,  it  would  have  been  much 
more  difficult  to  trace  any  errors  to  Apache,  mod_dav,  the  MYSEA  services  or  the 
underlying  STOP  6.1  operating  system.  Instead,  the  implementation  was  perfonned  in 
stages,  with  testing  conducted  at  each  stage  to  ensure  that  the  required  functionality  was 
preserved.  Table  2  contains  infonnation  about  the  platforms  used  in  each  stage. 

The  minimal  testing  perfonned  at  each  stage  consisted  of  connecting  to  the  server 
and  attempting  to  read  and  modify  an  existing  file.  This  testing  was  done  merely  to 
ensure  that  the  installation  had  been  successful  and  was  performed  with  the  client  on  the 
machine  running  Linux.  More  thorough  testing  will  be  discussed  in  Chapter  IV. 


Hardware 

OS 

Security  Context 

Apache  Version 

moddav  Version 

Stage  1 

Dell  Inspiron 

F  edora  Core  4 

N/A 

1.3.34 

1.0.3 

Stage  2 

XTS-400 

STOP  6.1 

Single  Level 

1.3.34 

1.0.3 

Stage  3 

XTS-400 

STOP  6.1 

Multilevel 

1.3.34 

1.0.3 

Table  2.  Stage  Platform  Information 
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1.  Linux 

For  the  first  stage,  Apache  1.3.34  [8]  and  mod_dav  1.0.3  [9]  were  downloaded 
and  installed  on  a  Dell  laptop  running  Linux,  specifically  Fedora  Core  4  [10].  Here  the 
purpose  was  familiarization  with  the  installation  and  use  of  WebDAV  and  Apache. 
Apache  was  chosen  for  use  not  only  because  it  is  among  the  most  widely  used  web 
servers  but  because  it  is  already  installed  and  operating  in  the  MYSEA  testbed.  Adding 
moddav,  an  Apache  module  to  enable  the  use  of  WebDAV,  to  the  existing  Apache 
server  seemed  to  be  the  most  straightforward  route  to  implementing  WebDAV  in  the 
MYSEA  environment.  Using  the  documentation  that  accompanied  the  downloaded  files, 
both  Apache  and  mod  dav  were  compiled  and  installed  without  incident.  After  the 
successful  completion  of  a  few  basic  tests  that  demonstrated  the  operation  of  WebDAV 
in  a  standard  environment  it  was  decided  to  move  on  to  the  next  step. 

2.  Single  Level  XTS 

After  familiarization  with  the  XTS-400,  the  same  versions  of  Apache  and 
mod  dav  as  are  discussed  in  the  previous  section  were  downloaded,  installed  and 
configured  on  the  XTS-400  running  the  STOP  6.1  [1 1]  operating  system.  For  this  phase, 
Apache  was  configured  to  run  as  a  standalone  server  at  a  single  classification  level.  The 
security  level  of  this  server  needed  to  be  secrecy  level  1  and  integrity  level  3  since  the 
network  interface  chosen  for  use  is  configured  to  be  accessible  only  as  this  level.  The 
only  hurdles  to  this  goal  were  those  related  to  familiarization  with  the  new  operating 
system,  specifically  problems  associated  with  properly  starting  the  networking  services. 
Since  the  installation  and  configuration  were  identical  to  those  of  the  Linux  system,  it 
took  very  little  time  to  set  up  Apache  with  mod  dav  at  a  single  level  on  the  XTS-400. 
Some  basic  functionality  tests  were  successfully  performed;  these  ensured  that  the 
installation  had  been  performed  properly.  After  these  encouraging  results  the  next  step 
was  to  install  and  configure  mod  dav  in  the  multilevel  environment. 

3.  Multilevel  XTS 

For  a  single  Apache  server  to  be  available  at  multiple  levels,  it  must  be  set  up  as 
an  inetd  service,  bound  to  a  specific  port  and  registered  with  the  MYSEA  daemon.  The 
MYSEA  services  behave  similarly  to  the  classic  inetd  service  in  that  they  listen  for  new 
incoming  connections  and  spawns  new  processes  as  appropriate  to  handle  incoming 
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requests.  The  difference  is  that  the  MYSEA  services  will  spawn  the  new  process  at  the 
same  security  and  integrity  level  as  the  negotiated  level  of  the  incoming  request. 
However,  for  a  service  to  work  like  this  in  MYSEA,  application  code  must  be  modified 
to  use  a  form  of  virtual  sockets  implemented  in  the  MYSEA  system  rather  than  the 
standard  socket  implementation. 

Since  Apache  1.3.12  [12]  had  already  been  modified  to  use  the  virtual  sockets, 
and  since  moddav  is  advertised  in  the  documentation  as  being  compatible  with  versions 
of  Apache  as  old  as  1.3.6  [3],  an  attempt  was  made  to  install  mod  dav  with  the  existing 
Apache  installation.  Unfortunately,  mod  dav  did  not  work  with  this  setup.  Apache  still 
worked  after  installing  mod  dav,  but  any  attempt  to  use  the  new  protocol  methods 
specific  to  WebDAV  was  met  with  a  405  “Method  Not  Allowed”  error. 

To  ensure  that  this  error  was  not  simply  caused  by  the  code  modifications 
interfering  with  moddav,  an  unmodified  version  of  Apache  1.3.12  was  tested  at  a  single 
level,  as  was  successfully  done  with  Apache  1.3.34  previously.  However,  the  same  error 
occurred.  It  was  then  decided  to  test  an  unmodified  version  of  Apache  1.3.12  on  Fedora 
Core  4.  This  was  to  ensure  that  the  problem  wasn’t  associated  with  the  XTS-400. 
Surprisingly,  this  attempt  was  met  with  the  same  error  as  before,  even  though  mod  dav 
documentation  claims  that  it  works  with  Apache  1.3.12.  Rather  than  spend  more  time 
attempting  to  determine  the  cause  of  the  error,  it  was  decided  that  the  best  course  of 
action  would  be  to  make  the  appropriate  modifications  to  Apache  1.3.34  in  order  to  get  it 
to  function  with  the  MYSEA  services. 

Once  the  MYSEA  installation  of  Apache  had  been  upgraded  to  version  1.3.34, 
another  attempt  was  made  to  install  and  utilize  mod  dav  in  the  MYSEA  environment. 
With  only  a  slight  modification  to  the  installation  procedure  and  configuration  from  the 
previous  stages,  mod  dav  was  successfully  installed  and  run.  Basic  testing  confirmed  that 
mod  dav  was  indeed  functioning  correctly.  Comprehensive  testing  was  subsequently 
performed,  the  procedures  and  results  of  which  are  described  in  Chapter  IV. 
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E.  SUMMARY 

This  chapter  explained  the  goals  of  this  thesis,  described  the  design  of  the  file 
system  structure,  provided  a  concept  of  operation  and  detailed  the  steps  taken  to 
incorporate  WebDAV  in  various  environments.  The  next  chapter  will  outline  a  test  plan 
to  ensure  that  both  functional  and  security  requirements  are  met  as  well  as  describe  the 
details  of  the  test  results. 
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IV.  TESTING  AND  RESULTS 


This  chapter  will  detail  the  functional  and  security  tests  for  the  use  of  WebDAV 
in  various  settings  and  capacities.  Functional  testing  is  required  in  order  to  compare  the 
actual  WebDAV  functionality  to  the  expected  functionality.  The  functional  tests  confirm 
whether  the  functionality  expected  of  the  system  is  operable  and  provide  a  quantifiable 
measurement  of  the  ability  of  the  system  to  successfully  perform  the  desired  tasks.  The 
tests  perfonned  fall  into  three  categories:  Linux,  Single  Level  XTS  and  Multilevel  XTS. 
Each  of  these  categories  corresponds  to  a  stage  as  described  in  Table  2  in  the  previous 
chapter. 


© 


Figure  5.  Test  Network  Topology 
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Security  testing  is  required  to  ensure  that  the  MAC  and  DAC  policies  are 
correctly  enforced.  Since  the  DAC  policies  on  the  Linux  may  be  implemented  differently 
than  those  on  the  XTS-400,  only  the  two  XTS  stages  were  tested  for  security.  The 
security  tests  perfonned  fall  into  two  categories:  Single  Level  XTS  and  Multilevel  XTS. 
In  the  multilevel  category,  the  testing  scope  was  expanded  to  encompass  the  added 
security  parameter  possibilities. 

All  testing  was  performed  on  a  small  network  with  five  computers  connected  via 
a  switch,  as  illustrated  in  Figure  5.  The  operating  systems  used  on  the  five  systems  will 
be:  Fedora  Core  4,  Windows  XP,  Mac  OS  X  10.3  and  STOP  6.1  (as  part  of  the  XTS- 
400).  The  Windows,  Mac  and  Linux  systems  were  used  as  the  clients,  whereas  a  Linux 
system  and  the  XTS-400  acted  as  the  server  in  different  implementation  phases  illustrated 
in  Table  2  of  Chapter  III.  In  all  three  cases,  the  Windows  computer,  the  Macintosh  and  at 
least  one  of  the  Linux  computers  were  used  as  clients  to  test  the  WebDAV  server.  On  the 
Windows  and  Macintosh  machines,  the  built  in  WebDAV  client  was  used.  On  the  Linux 
clients,  both  the  built  in  WebDAV  client  and  an  open  source  client,  called  Cadaver,  were 
used.  Simultaneous  connections  from  multiple  clients  were  tested  with  no  issues. 


A.  FUNCTIONAL  TEST  PLAN 

Tests  were  performed  on  both  files  and  directories.  The  functions  tested  in  each 
implementation  were  as  follows:  read,  write,  create,  lock,  unlock,  delete,  make  directory, 
change  directory  and  delete  directory.  These  functions  were  tested  with  all  four  types  of 
WebDAV  clients. 

The  success  or  failure  of  a  particular  test  is  indicated  with  a  simple  pass/fail 
notation.  The  requirement  for  a  “pass”  mark  is  only  that  the  desired  outcome  is  achieved. 
All  of  these  tests  are  expected  to  pass  where  the  related  function  has  been  implemented  in 
the  client. 
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Test  # 

Test  Type 

Test  Description 

At 

Read 

Test  A 1  ensures  that  files  can  be  read  via  the 
WebDAV  client. 

A2 

Write 

Test  A2  ensures  that  files  can  be  written  via  the 
WebDAV  client. 

A3 

Create 

Test  A3  ensures  that  files  can  be  created  via  the 
WebDAV  client. 

A4 

Lock 

Test  A4  ensures  that  files  can  be  locked  via  the 
WebDAV  client. 

A5 

Unlock 

Test  A5  ensures  that  files  can  be  unlocked  via  the 
WebDAV  client. 

A6 

Delete 

Test  A6  ensures  that  files  can  be  deleted  via  the 
WebDAV  client. 

A7 

Make  Directory 

Test  A7  ensures  that  directories  can  be  created  via 
the  WebDAV  client. 

A8 

Change  Directory 

Test  A8  ensures  that  directories  can  be  traversed  via 
the  WebDAV  client. 

A9 

Delete  Directory 

Test  A9  ensures  that  directories  can  be  deleted  via 
the  WebDAV  client. 

A10 

Read  Nonexistent  File 

Test  A10  ensures  that  no  unrecoverable  errors  occur 
when  attempting  to  read  a  file  that  does  not  exist. 

All 

Delete  Nonexistent  File 

Test  A1 1  ensures  that  no  unrecoverable  errors  occur 
when  attempting  to  delete  a  file  that  does  not  exist. 

A12 

Lock  Nonexistent  File 

Test  A12  ensures  that  no  unrecoverable  errors  occur 
when  attempting  to  lock  a  file  that  does  not  exist. 

A13 

Unlock  Nonexistent  File 

Test  A13  ensures  that  no  unrecoverable  errors  occur 
when  attempting  to  unlock  a  file  that  does  not  exist. 

A14 

Delete  Nonexistent  Directory 

Test  A14  ensures  that  no  unrecoverable  errors  occur 
when  attempting  to  delete  a  directory  that  does  not 
exist. 

Table  3.  Functional  Test  Descriptions 


B.  LINUX  TESTING 

The  functional  tests  performed  using  Linux  as  the  server  define  a  baseline  of 
functionality  desired  for  a  WebDAV  server.  In  other  words,  if  a  particular  function  did 
not  work  on  the  Linux  implementation  of  the  WebDAV  server,  then  it  is  not  expected  to 
work  on  the  XTS-400  implementation  either. 

1.  Test  Results 

All  of  the  clients  tested  performed  perfectly,  with  one  exception.  The  exception  is 
that  all  of  the  graphical  clients,  the  ones  that  were  built  into  the  various  operating 
systems,  had  no  facilities  for  locking  or  unlocking  files  or  directories,  or  interacting  with 
nonexistent  files  or  directories.  Cadaver,  however,  was  able  to  lock  and  unlock  both  files 
and  directories  with  ease.  Files  that  were  locked  with  Cadaver  were  unable  to  be 
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overwritten  by  any  client,  but  they  could  still  be  read  (as  should  be  the  case).  Test  results 
marked  “N/A”  were  those  that  cannot  be  performed  with  graphical  clients,  as  noted 
above. 


Test  # 

Test  Type 

Windows 

Explorer 

Macintosh 

Finder 

Linux 

Gnome 

Cadaver 

A1 

Read 

Pass 

Pass 

Pass 

Pass 

A2 

Write 

Pass 

Pass 

Pass 

Pass 

A3 

Create 

Pass 

Pass 

Pass 

Pass 

A3 

Lock 

N/A 

N/A 

N/A 

Pass 

A4 

Unlock 

N/A 

N/A 

N/A 

Pass 

A5 

Delete 

Pass 

Pass 

Pass 

Pass 

A6 

Make  Directory 

Pass 

Pass 

Pass 

Pass 

A7 

Change  Directory 

Pass 

Pass 

Pass 

Pass 

A8 

Delete  Directory 

Pass 

Pass 

Pass 

Pass 

A9 

Read  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A10 

Delete  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

All 

Lock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A12 

Unlock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A13 

Delete  Nonexistent  Directory 

N/A 

N/A 

N/A 

Pass 

Table  4.  Linux  Server  Functional  Test  Results 


C.  SINGLE  LEVEL  XTS  TESTING 

The  tests  described  in  this  section  were  performed  on  the  XTS-400  and  were 
designed  to  test  that  the  relevant  MAC  security  constraints  are  met  by  the  implementation 
and  that  no  functionality  was  lost  in  the  transition  from  the  Linux  server  to  the  XTS-400 
single  level  implementation. 

1.  Security  Test  Plan 

The  set  of  tests  described  in  Table  5  were  designed  to  determine  whether  or  not 
the  MAC  secrecy  constraints  are  adequately  enforced  over  a  WebDAV  connection.  Since 
this  implementation  of  the  server  is  bound  to  a  single  security  level,  only  variance  in  the 
security  levels  of  the  objects  being  accessed  can  be  tested. 
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Test  # 

Test  Type 

Session  Level 

Object  Level 

Operation 

Expected  Result 

B1 

Secrecy  Read  Up 

si  1  :il3 

s!2:il3 

Read 

Fail 

Test  B1  ensures  that  a  user  is  not  able  to  read  data  from  a  secrecy  level  higher  than  the  level  of  the 
currently  established  session. 

B2 

Secrecy  Read  Down 

si  1  :il3 

sl0:il3 

Read 

Pass 

Test  B2  ensures  that  a  user  is  able  to  read  data  from  a  secrecy  level  lower  than  the  level  of  the 
currently  established  session. 

B3 

Secrecy  Read  Equal 

si  1  :il3 

si  1 :  il3 

Read 

Pass 

Test  B3  ensures  that  a  user  is  able  to  read  data  from  a  secrecy  level  equal  to  the  level  of  the 
currently  established  session. 

B4 

Secrecy  Write  Up 

si  1  :il3 

sl2:il3 

Write 

Fail 

Test  B4  ensures  that  a  user  is  not  able  to  write  data  to  a  secrecy  level  higher  than  the  level  of  the 
currently  established  session. 

B5 

Secrecy  Write  Down 

si  1  :il3 

sl0:il3 

Write 

Fail 

Test  B5  ensures  that  a  user  is  not  able  to  write  data  to  a  secrecy  level  lower  than  the  level  of  the 
currently  established  session. 

B6 

Secrecy  Write  Equal 

si  1  :il3 

si  1 :  il3 

Write 

Pass 

Test  B6  ensures  that  a  user  is  able  to  write  data  to  a  secrecy  level  equal  to  the  level  of  the 
currently  established  session. 

Table  5.  Single  Level  Security  Tests 


2.  Test  Results 

As  Table  6  shows,  the  results  of  the  functional  tests  were  the  same  as  those 
performed  with  the  Linux  server.  This  indicates  that  no  functionality  was  changed  during 
the  transition  to  the  XTS-400. 


Test  # 

Test  Type 

Windows 

Explorer 

Macintosh 

Finder 

Linux 

Gnome 

Cadaver 

A1 

Read 

Pass 

Pass 

Pass 

Pass 

A2 

Write 

Pass 

Pass 

Pass 

Pass 

A3 

Create 

Pass 

Pass 

Pass 

Pass 

A3 

Lock 

N/A 

N/A 

N/A 

Pass 

A4 

Unlock 

N/A 

N/A 

N/A 

Pass 

A5 

Delete 

Pass 

Pass 

Pass 

Pass 

A6 

Make  Directoiy 

Pass 

Pass 

Pass 

Pass 

A7 

Change  Directory 

Pass 

Pass 

Pass 

Pass 

A8 

Delete  Directory 

Pass 

Pass 

Pass 

Pass 

A9 

Read  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A10 

Delete  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

All 

Lock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A12 

Unlock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A13 

Delete  Nonexistent  Directoiy 

N/A 

N/A 

N/A 

Pass 

Table  6.  Single  Level  XTS  Server  Functional  Test  Results 
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The  results  in  Table  7  show  that  all  of  the  tested  clients  interacted  with  the  server 
as  expected  when  faced  with  MAC  secrecy  constraints  of  the  types  shown.  These  results 
are  encouraging  and  show  that,  at  least  for  basic  secrecy  interactions,  the  MAC  policies 
are  properly  enforced  over  WebDAV. 


Test  # 

Test  Type 

Windows 

Macintosh 

Linux 

Cadaver 

B1 

Secrecy  Read  Up 

Fail 

Fail 

Fail 

Fail 

B2 

Secrecy  Read  Down 

Pass 

Pass 

Pass 

Pass 

B3 

Secrecy  Read  Equal 

Pass 

Pass 

Pass 

Pass 

B4 

Secrecy  Write  Up 

Fail 

Fail 

Fail 

Fail 

B5 

Secrecy  Write  Down 

Fail 

Fail 

Fail 

Fail 

B6 

Secrecy  Write  Equal 

Pass 

Pass 

Pass 

Pass 

Table  7.  Single  Level  XTS  Server  Security  Test  Results 


D.  MULTILEVEL  XTS  TESTING 

The  tests  described  in  this  section  were  performed  on  the  XTS-400  and  were 
designed  to  test  that  the  relevant  MAC  security  constraints  are  met  by  the  implementation 
and  that  no  functionality  was  lost  in  the  transition  from  the  single  level  to  the  multilevel 
implementation  on  the  XTS-400. 

1.  Security  Test  Plan 

The  set  of  tests  described  in  Table  8  were  designed  to  determine  whether  or  not 
the  MAC  and  DAC  security  constraints  are  adequately  enforced  over  a  WebDAV 
connection.  This  implementation  of  the  server  is  able  to  operate  with  sessions  established 
at  different  secrecy  and  integrity  levels,  so  appropriate  tests  that  varied  the  secrecy  and 
integrity  levels  of  both  the  session  and  the  objects  were  performed. 

Since  many  different  users  can  establish  a  session  with  the  server,  tests  were  also 
included  to  ensure  that  the  DAC  policies  were  also  adhered  to.  These  tests  were 
performed  with  the  owner  of  the  session  and  the  owner  of  the  object  differing  from  each 
other.  The  secrecy  levels  of  the  objects  were  also  varied  to  make  sure  a  “high”  user  can 
not  access  the  files  of  a  different  “low”  user,  and  vice  versa,  in  an  unauthorized  manner. 
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Test  # 

Test  Type 

Session  Level 

Object  Level 

Operation 

Expected  Result 

Cl 

Secrecy  Read  Up 

si  1  :il3 

sl2:il3 

Read 

Fail 

C2 

sl2:il3 

sl3:il3 

Read 

Fail 

C3 

s!3:il3 

sl4:il3 

Read 

Fail 

Tests  Cl  through  C3  ensure  that  a  user  is  not  able  to  read  data  from  a  secrecy  level 
higher  than  the  level  of  the  currently  established  session. 

C4 

Secrecy  Read  Down 

si  1  :il3 

sl0:il3 

Read 

Pass 

C5 

sl2:il3 

sll  :il3 

Read 

Pass 

C6 

s!3:il3 

sl2:il3 

Read 

Pass 

Tests  C4  through  C6  ensure  that  a  user  is  able  to  read  data  from  a  secrecy  level  lower 
than  the  level  of  the  currently  established  session. 

C7 

Secrecy  Read  Equal 

si  1  :il3 

sll  :il3 

Read 

Pass 

C8 

sl2:il3 

sl2:il3 

Read 

Pass 

C9 

s!3:il3 

s!3:il3 

Read 

Pass 

Tests  C7  through  C9  ensure  that  a  user  is  able  to  read  data  from  a  secrecy  level  equal 
to  the  level  of  the  currently  established  session. 

CIO 

Secrecy  Write  Up 

si  1  :il3 

sl2:il3 

Write 

Fail 

Cll 

sl2:il3 

sl3:il3 

Write 

Fail 

C12 

s!3:il3 

sl4:il3 

Write 

Fail 

Tests  CIO  through  C12  ensure  that  a  user  is  not  able  to  write  data  to  a  secrecy  level 
higher  than  the  level  of  the  currently  established  session. 

C13 

Secrecy  Write  Down 

si  1  :il3 

sl0:il3 

Write 

Fail 

C14 

sl2:il3 

sll  :il3 

Write 

Fail 

C15 

s!3:il3 

sl2:il3 

Write 

Fail 

Tests  Cl 3  through  Cl 5  ensure  that  a  user  is  not  able  to  write  data  to  a  secrecy  level 
lower  than  the  level  of  the  currently  established  session. 

C16 

Secrecy  Write  Equal 

si  1  :il3 

sll  :il3 

Write 

Pass 

C17 

sl2:il3 

sl2:il3 

Write 

Pass 

C18 

s!3:il3 

s!3:il3 

Write 

Pass 

Tests  C16  through  Cl 8  ensure  that  a  user  is  able  to  write  data  to  a  secrecy  level  equal 
to  the  level  of  the  currently  established  session. 

C19 

DAC  Read  Down 

si  1  :il3 

s!0:il3 

Read 

Fail 

Test  C19  ensures  that  a  user  is  not  able  to  read  data  from  a  file  that  is  owned  by 
another  user,  has  permissions  set  to  allow  only  the  owner  to  read  and  has  a  secrecy 
level  lower  than  the  level  of  the  currently  established  session. 

C20 

DAC  Read  Equal 

si  1  :il3 

sll  :il3 

Read 

Fail 

Test  C20  ensures  that  a  user  is  not  able  to  read  data  from  a  file  that  is  owned  by 
another  user,  has  permissions  set  to  allow  only  the  owner  to  read  and  has  a  secrecy 
level  equal  to  the  level  of  the  currently  established  session. 

C21 

DAC  Write  Equal 

sll  :i!3 

sll  :il3 

Write 

Fail 

Test  C21  ensures  that  a  user  is  not  able  to  write  data  to  a  file  that  is  owned  by  another 
user,  has  permissions  set  to  allow  only  the  owner  to  write  and  has  a  secrecy  level  equal 
to  the  level  of  the  currently  established  session. 

C22 

Multiple  Lock 

sll  :il3 

sll  :il3 

Lock 

Fail 

Test  C22  ensures  that  multiple  users  are  not  able  to  lock  the  same  file  simultaneously. 

C23 

Multiple  Lock/Write 

sll  :il3 

sll  :il3 

Lock/Write 

Fail 

Test  C23  ensures  that  a  user  is  not  able  to  write  to  a  file  that  has  been  locked  by 
another  user. 

Table  8.  Multilevel  Security  Tests 
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2.  Test  Results 

As  Table  9  shows,  the  results  of  the  functional  tests  were  the  same  as  the  results 
of  the  tests  performed  with  the  Linux  server  and  the  server  running  on  the  XTS-400  at  a 
single  level.  This  indicates  that  no  functionality  was  changed  during  the  transition  to  the 
multilevel  XTS-400  environment. 


Test  # 

Test  Type 

Windows 

Explorer 

Macintosh 

Finder 

Linux 

Gnome 

Cadaver 

At 

Read 

Pass 

Pass 

Pass 

Pass 

A2 

Write 

Pass 

Pass 

Pass 

Pass 

A3 

Create 

Pass 

Pass 

Pass 

Pass 

A3 

Lock 

N/A 

N/A 

N/A 

Pass 

A4 

Unlock 

N/A 

N/A 

N/A 

Pass 

A5 

Delete 

Pass 

Pass 

Pass 

Pass 

A6 

Make  Directory 

Pass 

Pass 

Pass 

Pass 

A7 

Change  Directory 

Pass 

Pass 

Pass 

Pass 

A8 

Delete  Directory 

Pass 

Pass 

Pass 

Pass 

A9 

Read  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A10 

Delete  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

All 

Lock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A12 

Unlock  Nonexistent  File 

N/A 

N/A 

N/A 

Pass 

A13 

Delete  Nonexistent  Directory 

N/A 

N/A 

N/A 

Pass 

Table  9.  Multilevel  XTS  Server  Functional  Test  Results 


The  results  in  Table  10  show  that  all  of  the  tested  clients  interacted  with  the  server 
as  expected  when  faced  with  MAC  and  DAC  constraints  of  the  types  shown.  These 
results  are  encouraging  and  show  that  even  for  complex  security  interactions,  the  MAC 
and  DAC  policies  are  properly  enforced  over  WebDAV. 
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Test  # 

Test  Type 

Windows 

Macintosh 

Linux 

Cadaver 

Cl 

Secrecy  Read  Up 

Fail 

Fail 

Fail 

Fail 

C2 

Fail 

Fail 

Fail 

Fail 

C3 

Fail 

Fail 

Fail 

Fail 

C4 

Secrecy  Read  Down 

Pass 

Pass 

Pass 

Pass 

C5 

Pass 

Pass 

Pass 

Pass 

C6 

Pass 

Pass 

Pass 

Pass 

C7 

Secrecy  Read  Equal 

Pass 

Pass 

Pass 

Pass 

C8 

Pass 

Pass 

Pass 

Pass 

C9 

Pass 

Pass 

Pass 

Pass 

CIO 

Secrecy  Write  Up 

Fail 

Fail 

Fail 

Fail 

Cll 

Fail 

Fail 

Fail 

Fail 

C12 

Fail 

Fail 

Fail 

Fail 

C13 

Secrecy  Write  Down 

Fail 

Fail 

Fail 

Fail 

C14 

Fail 

Fail 

Fail 

Fail 

C15 

Fail 

Fail 

Fail 

Fail 

C16 

Secrecy  Write  Equal 

Pass 

Pass 

Pass 

Pass 

C17 

Pass 

Pass 

Pass 

Pass 

C18 

Pass 

Pass 

Pass 

Pass 

C19 

DAC  Read  Down 

Fail 

Fail 

Fail 

Fail 

C20 

DAC  Read  Equal 

Fail 

Fail 

Fail 

Fail 

C21 

DAC  Write  Equal 

Fail 

Fail 

Fail 

Fail 

C22 

Multiple  Lock 

N/A 

N/A 

N/A 

Fail 

C23 

Multiple  Lock/Write 

N/A 

N/A 

N/A 

Fail 

Table  10.  Multilevel  XTS  Server  Security  Test  Results 


E.  PROBLEMS  ENCOUNTERED 

There  was  only  one  major  problem  encountered  during  the  testing  of  the 
WebDAV  servers,  and  it  occurred  only  with  the  instance  installed  in  the  multilevel 
environment.  When  accessing  one  of  the  directories  that  contained  subdirectories  with 
varying  security  levels,  the  “/home/http/htdocs/dav/public/”  directory  for  example,  any 
attempt  to  list  the  contents  of  the  directory  via  WebDAV  failed  unless  the  current  session 
was  at  the  same  level  as  the  highest  level  subdirectory  present.  For  example,  say  a 
directory  has  three  subdirectories  at  the  levels  s/0:i/3,  sll:i/3  and  sl2:il3.  If  a  user  with  a 
session  established  at  sll:il3  attempts  to  list  the  contents  of  this  directory  with  WebDAV, 
the  operation  will  fail.  If  another  user  with  a  session  established  at  sl2:il3  attempts  to  list 
the  contents  of  this  directory  with  WebDAV,  the  operation  will  succeed. 

In  order  to  fix  this  problem,  the  source  code  for  mod  dav  will  likely  need  to  be 
edited.  It  is  suspected  that  the  failure  stems  from  the  use  of  a  stat()  function  to  determine 

the  properties  of  the  contents  of  the  directories.  The  stat()  function  is  likely  to  fail  when 
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attempted  on  a  directory  with  a  level  higher  than  that  of  the  current  session.  Since 
moddav  is  not  multilevel  aware  and  does  not  expect  the  stat()  function  to  fail,  moddav 
returns  an  error  rather  than  a  partial  directory  listing. 

This  error  should  be  possible  to  fix  with  minimum  effort,  pinpointing  the  exact 
cause,  however,  could  prove  difficult.  It  has  been  decided  that  rectifying  this  error  is 
beyond  the  scope  of  this  thesis. 


F.  SUMMARY 

This  chapter  explained  both  the  functional  and  security  tests  performed  on  three 
instances  of  the  WebDAV  server:  on  Linux,  on  the  XTS-400  at  a  single  level  and  on  the 
XTS-400  at  multiple  levels.  In  addition  the  results  of  the  tests  were  explained.  The  next 
chapter  will  discuss  the  results  and  conclusions  of  the  work  perfonned  and  will  suggest 
possible  future  work  in  related  areas. 
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V.  CONCLUSION  AND  FUTURE  WORK 


This  chapter  will  state  the  project  conclusions,  discuss  a  related  project  and 
suggest  possible  work  for  the  future. 


A.  CONCLUSION 

The  goal  of  this  thesis  is  to  utilize  WebDAV  in  the  MYSEA  multilevel 
environment  to  provide  users  on  the  MYSEA  MLS  network  with  remote  access  to  data 
whose  security  classification  is  dominated  by  the  security  level  of  the  currently 
authorized  session.  This  goal  has  been  successfully  achieved  through  the  use  of  Apache 
and  the  moddav  module  on  the  MYSEA  server.  The  tests  described  in  Chapter  IV 
confirmed  that  the  WebDAV  server  is  fully  functional  (with  the  only  limitations  being  in 
the  functions  implemented  in  some  of  the  clients)  and  that  it  adequately  enforces  the 
MAC  and  DAC  policies  of  the  MYSEA  server. 


B.  RELATED  WORK 

Galois  Connections,  Inc.  has  a  cross-domain  solutions  project  called  the  Trusted 
Services  Engine  (TSE)  that  utilizes  WebDAV  to  implement  a  MILS  file  system  that  is 
remotely  accessible  over  a  network.  [13]  The  major  difference  between  the  TSE  and  the 
way  WebDAV  is  used  in  the  MYSEA  environment  is  that  the  TSE  is  built  on  a  MILS 
kernel  that  requires  a  separate  hard  disk  and  an  independent  instance  of  each  server  at 
each  security  level  in  order  to  provide  multilevel  services.  This  approach  does  not  scale 
well  to  arbitrary  numbers  of  security  levels  since  each  additional  level  would  require  its 
own  hard  disk  and  another  instance  of  each  required  software  component.  The  MYSEA 
server  is  trusted  to  provide  multilevel  protection  while  using  only  one  shared  file  system. 
It  also  automatically  spawns  new  instances  of  each  server  process  at  the  appropriate 
security  level  as  new  connections  are  established. 
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C.  FUTURE  WORK 

There  were  two  major  issues  that  arose  through  the  work  on  this  thesis  that 
warrant  further  work. 

1.  Account  Setup 

The  first  issue  is  the  amount  of  effort  required  by  an  administrator  to  set  up 
individual  user  accounts  for  use  with  WebDAV.  As  it  stands,  an  administrator  must 
manually  create  various  directories  at  the  proper  security  levels  for  each  user  that  requires 
access  to  private  data  via  WebDAV.  Creating  and  setting  these  directories  to  various 
security  levels  is  a  time  consuming  process.  However,  this  process  can  be  automated. 

2.  Directory  Listing 

The  second  issue  is  the  inability  to  list  the  contents  of  directories  that  contain 
items  at  different  security  levels.  Although  this  problem  is  mostly  an  inconvenience,  it  is 
most  likely  possible  to  modify  the  source  code  for  the  mod  dav  module  in  such  a  way  as 
to  overcome  this  error. 

3.  Expanded  WebDAV  Access 

As  discussed  in  Section  B  of  Chapter  III,  the  third  future  work  item  is  to  set  up 
separate  instances  of  Apache  with  mod_dav  on  the  MYSEA  server,  one  for  each  of  the 
connected  single  level  networks.  Each  of  these  instances  would  share  the  same  document 
root,  which  could  also  coincide  with  the  document  root  used  by  the  server  in  this  thesis, 
thus  allowing  more  authorized  users  access  to  the  same  shared  data  at  multiple  levels 
while  still  allowing  for  “read  down”  capabilities. 
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APPENDIX  A:  INSTALLATION  PROCEDURES 


This  appendix  describes  the  installation  procedures  for  the  Apache  1.3.34  web 
server,  the  mod_dav  1.0.3  Apache  module  and  the  Cadaver  0.22.2  WebDAV  client. 
Instructions  for  testing  the  installation  and  using  various  WebDAV  clients  are  also 
provided.  Each  section  is  independent  and  does  not  depend  of  the  steps  performed  in  any 
other  section.  The  only  exception  is  that  the  testing  procedures  cannot  be  perfonned  until 
at  least  one  of  the  moddav  installations  had  occurred.  Each  set  of  instructions  will 
explicitly  state  which  operating  system  the  steps  are  to  be  performed  on. 

The  following  instructions  also  make  reference  to  the  Secure  Attention  Key 
(SAK).  On  the  XTS-400,  the  SAK  is  invoked  by  simultaneously  pressing  both  the  “Alt” 
and  “SysRq”  (a.k.a.  “Print  Screen”)  keys.  This  allows  special  trusted  commands  to  be 
performed.  Of  special  note  are  two  trusted  commands:  the  si  command  and  the  fsm 
command.  The  si  command  is  used  to  set  the  security  level  of  a  session  while  the  fsm 
command  is  used  to  view  and  edit  various  properties  (i.e.  the  MAC  and  DAC 
pennissions)  of  files  and  directories. 

A.  INSTALLATION  AND  TEST  TOPOLOGY 

The  network  topology  used  for  this  installation  and  testing  activity  consists  of 
four  computers  connected  via  a  switch  as  shown  in  Figure  5  of  Chapter  IV..  Of  these  four 
computers,  two  run  Fedora  Core  4,  one  Windows  XP  and  the  last  is  an  XTS-400  running 
the  STOP  6.1  operating  system. 

B.  LINUX  INSTALLATION 

All  of  the  procedures  in  this  section  are  to  be  performed  as  the  root  user  on  a 
machine  running  Fedora  Core  4.  These  procedures  download,  install  and  configure  the 
Apache  1.3.34  web  server  along  with  the  mod_dav  1.0.3  Apache  module. 

Step  1 .  Download  and  unpack  the  Apache  server  and  the  mod  dav  module  from 
the  installation  CD: 

cd  /root 

cp  /media/cdrom/apache  1 . 3 . 34 . tar . gz  ./ 
cp  /media/cdrom/mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz  ./ 
gunzip  apache  1 . 3 . 34 . tar . gz 
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tar  -xvf  apache  1.3. 34. tar 
gunzip  mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz 
tar  -xvf  mod  dav-1 . 0 . 3-1 . 3 . 6 . tar 


Step  2.  Build  and  install  moddav  into  the  Apache  source  directory.  While  this  is 
done  before  Apache  is  built  and  installed,  the  Apache  configuration  script  must  be  run 
first  to  ensure  that  certain  files  required  for  mod  dav  configuration  are  present. 


cd  /root/apache_l . 3 . 34 

. /configure  --prefix=/usr/local/apachel3 
cd  /root/mod_dav-l . 0 . 3-1 . 3 . 6 

./configure  --with-apache=/root/apache  1.3.34 
make 

make  install 


Step  3.  Build  and  install  Apache: 

cd  /root/apache_l . 3 . 34 

./configure  --pref ix=/usr/local/apachel3  --activate- 
module=src/modules/dav/libdav . a 

make 

make  install 


Step  4.  Save  and  edit  the  default  Apache  configuration: 


cd  /usr/local/apachel3/conf / 
cp  httpd.conf  httpd . conf . bak 
vi  httpd.conf 


Step  5.  Append  the  following  text  to  the  end  of  the  “httpd.conf’  file: 

DAVLockDB  /usr/local/apachel3/var/DAVLock 
CLocation  /dav> 

DAV  On 
</Location> 


Step  6.  Create  the  two  directories  referenced  in  the  configuration  lines  above: 


mkdir  /usr/local/apachel3/var 

mkdir  / us r/ local/ apache 1 3 /htdocs/dav 

/us r/ local /apache 13 /bin /apachectl  start 
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Once  all  of  these  steps  have  been  completed,  the  installation  and  configuration  of 
Apache  and  moddav  on  Fedora  Core  4  is  finished.  The  test  outlined  in  Section  F  of  this 
appendix  should  be  performed  to  ensure  that  the  installation  was  performed  correctly. 

C.  XTS  SINGLE  LEVEL  INSTALLATION 

All  of  the  procedures  in  this  section  are  to  be  performed  as  the  “admin”  user  on 
the  XTS-400.  These  procedures  download,  install  and  configure  the  Apache  1.3.34  web 
server  along  with  the  mod  dav  1.0.3  Apache  module.  For  this  section,  a  base  install  of 
the  MYSEA  package  on  an  XTS-400  running  the  STOP  6.1  operating  system  is  assumed. 

Step  1.  Download  the  Apache  server  and  the  mod  dav  module  from  the 
installation  CD.  A  special  tool,  named  cdtool,  is  used  on  the  XTS-400  to  transfer  files 
from  a  CD.  Unless  otherwise  noted,  the  steps  in  this  section  must  be  performed  at  the 
security  level  si  1  :il3  since  that  is  the  configured  level  of  the  network  interface  used  by  the 
server. 


(set  security  and  integrity  levels  -  min:oss) 

cd  /home/admin 

cdtool  cp  /apache  1 . 3 . 34 . tar . gz  ./apache  1 . 3 . 34 . tar . gz 
cdtool  cp  /mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz  ./mod  dav-1.0.3- 
1.3.6. tar . gz 


Step  2.  Change  the  security  level  of  the  downloaded  files  to  sll:il3 : 


SAK 

Enter  command? 

Enter  request? 

Enter  pathname? 

Modify  access  level? 

Enter  new  security  level? 
Enter  new  integrity  level? 

Is  the  level  correct? 

Enter  new  owner  name? 
Enter  new  group  name? 
Modify  discretionary  access? 
Display  the  object? 

Okay  to  change? 


f  sm 

change 

/home/http/htdocs/dav/public/sllil3 

yes 

sll 

il3 

yes 

admin 

stop 

no 

no 

yes 


Step  3.  Unpack  the  Apache  server  and  the  mod  dav  module: 
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(set  security  and  integrity  levels  -  sll:il3) 

gunzip  apache  1 . 3 . 34 . tar . gz 
tar  xvf  apache  1.3. 34. tar 
gunzip  mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz 
tar  xvf  mod  dav-1 . 0 . 3-1 . 3 . 6 . tar 

Step  4.  Build  and  install  moddav  into  the  Apache  source  directory.  While  this  is 
done  before  Apache  is  built  and  installed,  the  Apache  configuration  script  must  be  run 
first  to  ensure  that  certain  files  required  for  mod  dav  configuration  are  present. 

cd  /home/admin/apache  1.3.34 
. /configure  --pref ix=/home/sldav/apache 
cd  /home/admin/mod  dav-1 . 0 . 3-1 . 3 . 6 

./configure  --with-apache=/home/admin/apache  1.3.34 
make 

make  install 

Step  5.  Build  and  install  Apache: 

cd  /home/admin/apache  1.3.34 

./configure  --pref ix=/home/admin/apache  --activate- 
module=src/modules/dav/libdav . a 

make 

make  install 


Step  6.  Save  and  edit  the  default  Apache  configuration: 


cd  /home/sldav/apache/conf / 
cp  httpd.conf  httpd . conf . bak 
vi  httpd.conf 


Step  7.  Append  the  following  text  to  the  end  of  the  “httpd.conf’  file: 

DAVLockDB  /home/admin/apache/var/DAVLock 
CLocation  /dav> 

DAV  On 
</Location> 


Step  8.  Create  the  two  directories  referenced  in  the  configuration  lines  above: 


mkdir  /home/admin/apache/var 
mkdir  /home/admin/apache/htdocs/dav 
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Step  9.  Before  performing  this  step,  make  sure  that  the  network  interfaces  and 
daemons  have  been  started  using  the  trusted  startup  command. 

/home /admin /apache /bin/ apache ctl  start 

Once  all  of  these  steps  have  been  completed,  the  installation  and  configuration  of 
Apache  and  moddav  at  a  single  level  on  the  XTS-400  is  finished.  The  test  outlined  in 
Section  F  of  this  appendix  should  be  performed  to  ensure  that  the  installation  was 
performed  correctly. 

D.  XTS  MULTILEVEL  INSTALLATION 

All  of  the  procedures  in  this  section  are  to  be  performed  as  the  “admin”  user  on 
the  XTS-400,  except  where  otherwise  noted.  These  procedures  download,  install  and 
configure  the  mod  dav  1.0.3  Apache  module  with  the  existing  Apache  1.3.34  installation. 
For  this  section,  a  base  install  of  the  MYSEA  package  on  an  XTS-400  running  the  STOP 
6.1  operating  system  is  assumed. 

Step  1 .  Download  and  unpack  the  Apache  server  and  the  mod  dav  module  from 
the  installation  CD.  A  special  tool,  named  cdtool,  is  used  on  the  XTS-400  to  transfer  files 
from  a  CD. 


(set  security  and  integrity  levels  -  min:oss) 

cd  /home/admin 

cdtool  cp  /dev/cdrom  /mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz  ./mod  dav-1. 0.3- 
1.3.6. tar . gz 

gunzip  mod  dav-1 . 0 . 3-1 . 3 . 6 . tar . gz 
exit 

(set  security  and  integrity  levels  -  sl0:il3) 

cd  /usr/local/mysea/apache 

tar  xvf  /home/admin/mod  dav-1 . 0 . 3-1 . 3 . 6 . tar 
mv  mod  dav-1 . 0 . 3-1 . 3 . 6  mod  dav 


Step  2.  Edit  the  Apache  install  configuration: 


cd  /usr/local/mysea/apache/src 
vi  Configuration 
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Step  3.  Append  the  following  text  to  the  end  of  the  “Configuration”  file: 

AddModule  modules/dav/libdav. a 

Step  4.  Configure  moddav.  While  this  is  done  before  Apache  is  built,  the  Apache 
configuration  script  needs  to  be  run  first  to  ensure  that  certain  files  required  for  mod  dav 
configuration  are  present. 

. /Configure 

cd  /usr/ local /mys ea/ apache /mod_dav 
. /configure  --with-apache=/usr/local/mysea/apache 

Step  5.  Edit  the  mod  dav  makefile.  This  is  necessary  to  tell  mod  dav  where  to 
look  for  special  MYSEA  source  code  headers. 

vi  Makefile 

Step  6.  Find  the  line  that  starts  with  “ALL  CFLAGS  =  $(CPPFLAGS)”  and  add 
the  following  text  immediately  afterwards  on  the  same  line: 

-I /usr/ local /my sea/ include 

Step  7.  Build  and  install  mod  dav: 

make 

make  install 

Step  8.  Build  Apache: 

cd  /usr/local/mysea/apache/src 

. /Configure 

make 

Step  9.  Save  and  edit  the  default  Apache  configuration: 

cd  /home/http/conf / 
cp  httpd.conf  httpd . conf . bak 
vi  httpd.conf 
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Step  10.  Append  the  following  text  to  the  end  of  the  “httpd.conf  ’  file: 


DAVLockDB  /tmp/DAVLock 
CLocation  /dav> 

DAV  On 
</Location> 


Step  11.  Create  the  following  default  WebDAV  directories  for  both  the  public  and 
private  data  stores: 

mkdir  /home/http/htdocs/dav 
mkdir  /home /http/ ht do cs/dav/public 
mkdir  /home/http/htdocs/dav/public/sl0il3 
mkdir  /home/http/htdocs/dav/public/sllil3 
mkdir  /home/http/htdocs/dav/public/sl2il3 
mkdir  /home/http/htdocs/dav/public/sl3il3 
mkdir  /home/http/htdocs/dav/public/sl4il3 
mkdir  /home/http/htdocs/dav/public/sl5il3 
mkdir  / home /http/ ht do cs/dav/public/ si 6il3 
mkdir  /home/http/htdocs/dav/public/sl7il3 
mkdir  /home /http/ ht do cs/dav /private 


Step  12.  Set  all  of  the  directories  created  in  the  previous  step  to  the  proper 
security  levels.  This  is  done  in  the  trusted  environment  with  the  trusted  fsm  command. 
Repeat  this  process  to  set  each  directory  in  “/home/http/htdocs/dav/public/”  to  the 
security  level  described  by  its  name: 


(set  security  and  integrity  levels  -  sl0:il3) 


SAK 

Enter  command? 

Enter  request? 

Enter  pathname? 

Modify  access  level? 

Enter  new  security  level? 
Enter  new  integrity  level? 

Is  the  level  correct? 

Enter  new  owner  name? 
Enter  new  group  name? 
Modify  discretionary  access? 
Display  the  object? 

Okay  to  change? 


fsm 

change 

/home/http/htdocs/dav/public/ si li 13 

yes 

sll 

il3 

yes 

admin 

stop 

no 

no 

yes 
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Step  13.  For  each  user  who  needs  to  have  access  to  a  private  area  via  WebDAV, 
perform  the  following  steps.  The  username  “demo”  is  used  as  an  example  here  and  can  be 
replaced  with  any  valid  username. 


In  -s  /home/demo  /home/http/htdocs/dav/private/demo 

(log  in  as  “demo”  and  set  security  and  integrity  levels  -  sl0:il3) 

mkdir  /home /demo/ si Oi 13 
mkdir  /home /demo/ si li 13 
mkdir  /home /demo/ si 2 i 13 
mkdir  /home /demo/ si 3i 13 
mkdir  /home /demo/ si 4 i 13 
mkdir  /home /demo/ si 5i 13 
mkdir  /home/demo/sl6il3 
mkdir  /home /demo/ si 7 i 13 


Step  14.  Set  all  of  the  directories  created  in  step  10  to  the  proper  security  levels. 
This  is  done  in  the  trusted  environment  with  the  trusted  fsm  command.  Again,  the  user 
“demo”  is  used  as  an  example.  Repeat  the  following  process  to  set  each  directory  in 
“/home/demo”  to  the  security  level  described  by  its  name: 


(set  security  and  integrity  levels  - 
SAK 

sl0:il3) 

Enter  command? 

fsm 

Enter  request? 

change 

Enter  pathname? 

/ home / demo / s 1 1 i 1 3 

Modify  access  level? 

yes 

Enter  new  security  level? 

sll 

Enter  new  integrity  level? 

il3 

Is  the  level  correct? 

yes 

Enter  new  owner  name? 

demo 

Enter  new  group  name? 

other 

Modify  discretionary  access? 

yes 

Enter  object  modes  for  owner? 

rwx 

Enter  user  name? 

<CR> 

Enter  object  modes  for  group? 

none 

Enter  group  name? 

<CR> 

Enter  object  modes  for  others? 

none 

Display  the  object? 

no 

Okay  to  change? 

yes 

Once  all  of  these  steps  have  been  completed,  the  installation  and  configuration  of 
mod  dav  in  the  multilevel  environment  on  the  XTS-400  is  finished.  The  test  outlined  in 
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Section  F  of  this  appendix  should  be  performed  to  ensure  that  the  installation  was 
performed  correctly. 

E.  CADAVER  INSTALLATION 

All  of  the  procedures  in  this  section  are  to  be  performed  on  a  client  machine 
running  Fedora  Core  4.  These  procedures  download  and  install  the  Cadaver  0.22.2 
WebDAV  client  from  the  installation  CD. 

cp  /media/cdrom/cadaver-0 . 22 . 2 . tar  .  / 
tar  -xvf  cadaver-0 . 22 . 2 . tar 
cd  cadaver-0.22.2 
. /configure 
make 

make  install 

F.  INSTALLATION  TESTING 

The  following  procedures  are  designed  to  test  whether  or  not  the  installation  of 
moddav  into  Apache  was  successful.  Each  step  is  to  be  performed  on  the  operating 
system  specified. 

Step  1.  Create  a  file  on  the  machine  hosting  the  WebDAV  server  in  the  root  DAV 
directory  and  add  some  arbitrary  text: 

vi  readme.txt 

Step  2.  Access  the  file  created  in  Step  1  with  a  WebDAV  client  on  one  or  more 
operating  systems.  Section  G  of  this  appendix  contains  instructions  for  using  different 
WebDAV  clients  to  connect  to  a  WebDAV  server.  If  testing  the  MLS  WebDAV  server, 
log  in  and  establish  a  session  with  either  the  TPE  or  TCBE  client.  Using  one  of  the 
graphical  WebDAV  clients,  simply  double-click  on  “readme.txt”  in  the  WebDAV 
directory  to  ensure  that  it  is  accessible.  To  perform  the  same  check  with  Cadaver,  enter 
the  following  command  into  the  Cadaver  command  line: 

edit  readme.txt 

Step  3.  Attempt  to  upload  a  new  file  to  the  root  DAV  directory.  Once  again, 

connect  to  the  WebDAV  server  using  the  instructions  in  Section  G  of  this  appendix. 

Using  one  of  the  graphical  WebDAV  clients,  create  a  new  text  file  named  “upload.txt” 
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and  add  some  arbitrary  text  to  it.  Next  drag  the  new  “upload.txt”  file  to  the  connected 
WebDAV  directory.  To  perform  the  same  check  with  Cadaver,  enter  the  following 
command  into  the  Cadaver  command  line  and  add  some  arbitrary  text: 

edit  upload.txt 

Step  4.  Ensure  that  “upload.txt”  exists  on  the  machine  hosting  the  WebDAV 
server  and  that  it  contains  the  proper  text.  The  command  to  check  the  contents  of  the  file 
is: 

vi  upload.txt 

If  all  of  the  above  procedures  were  successfully  performed,  then  the  installation  of 
moddav  has  been  successful. 

G.  WEBDAV  CLIENT  INSTRUCTIONS 

This  section  provides  instructions  for  using  four  different  WebDAV  clients  to 
connect  to  a  WebDAV  server.  For  each  of  these  sets  of  instructions,  assume  the  IP 
address  of  the  WebDAV  server  is  192.168.0.130,  since  this  is  the  default  address  of  the 
port  interfacing  with  the  MLS  network  on  the  MYSEA  server. 

1.  Windows  XP 

From  any  Window  Explorer  window,  type  the  following  into  the  address  bar: 

\\1 92 .168.0 . 130\dav 

The  connection  is  now  established  and  the  WebDAV  directory  can  be  accessed  in 
the  same  manner  as  a  normal  directory. 

2.  Fedora  Core  4  Linux 

Select  the  “Connect  to  Server...”  option  from  the  “Places”  menu  and  enter  the 
following  options: 

Service:  WebDAV  (HTTP) 

Server:  192.168.0.130 

Port:  8  0 

Folder:  dav 
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The  connection  is  now  established  and  the  WebDAV  directory  can  be  accessed  in 
the  same  manner  as  a  normal  mounted  network  drive. 

3.  Macintosh  OS  10.3 

From  the  Finder,  select  the  “Connect  to  Server...”  option  from  the  “Go”  menu 
and  type  the  following  in  the  address  bar: 

http: //192. 168.0. 130/dav 

The  connection  is  now  established  and  the  WebDAV  directory  can  be  accessed  in 
the  same  manner  as  a  normal  mounted  network  drive. 

4.  Cadaver 

From  terminal,  type  the  following  command: 

cadaver  1 92 . 1 68 . 0 . 130/dav 

The  connection  is  now  established  and  the  WebDAV  directory  can  be  accessed  in 
a  similar  manner  as  a  normal  FTP  session. 
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APPENDIX  B:  TEST  PROCEDURES 


These  procedures  describe  the  steps  to  perform  the  tests  outlined  in  Chapter  IV. 
Each  test  falls  into  two  categories:  graphical  clients  and  Cadaver.  The  graphical  clients 
are  those  clients  that  are  built  in  to  Fedora  Core  4,  Windows  XP  and  Mac  OS  X.  These 
graphical  clients  are  accessed  through  the  graphical  user  interface  (GUI)  of  their  host 
operating  systems.  Cadaver  is  a  command  line  WebDAV  client  that  can  be  installed  on 
any  UNIX  based  operating  system  using  the  instructions  in  Appendix  A.  Instructions  for 
using  all  of  these  clients  are  found  in  Appendix  A. 

A.  FUNCTIONAL  TEST  PROCEDURES 

These  tests  are  to  be  performed  on  all  three  of  the  installation  types  described  in 
Appendix  A.  All  of  these  tests  assume  that  the  file  "readme.txt"  exists  on  the  WebDAV 
server  in  the  root  DAV  directory,  and  that  "readme.txt'  and  "upload.txt"  exists  on  the 
desktop  of  the  client  system  used  for  testing.  Each  of  these  files  should  contain  some 
uniquely  identifying  text  to  ensure  that  operations  were  indeed  successful.  Each  of  these 
tests  should  be  able  to  be  successfully  performed,  unless  stated  otherwise. 

Test  A1  intended  to  ensure  that  files  can  be  read  via  the  WebDAV  client. 

Graphical  Clients: 

Double  click  on  "readme.txt"  in  the  DAV  directory. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

edit  readme.txt 

Test  A2  intended  to  ensure  that  files  can  be  written  via  the  WebDAV  client. 

Graphical  Clients: 

Drag  the  file  "readme.txt"  from  the  desktop  to  the  DAV  directory. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 
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edit  readme.txt 


Add  some  arbitrary  text  to  the  file  and  save  it. 

Test  A3  ensures  that  files  can  be  created  via  the  WebDAV  client. 
Graphical  Clients: 

Drag  the  file  "upload.txt"  from  the  desktop  to  the  DAV  directory. 
Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

edit  upload2.txt 

Add  some  arbitrary  text  to  the  file  and  save  it. 

Test  A4  ensures  that  files  can  be  locked  via  the  WebDAV  client. 
Graphical  Clients: 

Files  cannot  be  locked  using  any  of  the  graphical  clients. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

lock  upload2.txt 

Test  A5  ensures  that  files  can  be  unlocked  via  the  WebDAV  client. 
Graphical  Clients: 

Files  cannot  be  unlocked  using  any  of  the  graphical  clients. 
Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

unlock  upload2.txt 

Test  A6  ensures  that  files  can  be  deleted  via  the  WebDAV  client. 
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Graphical  Clients: 

Select  the  file  "upload.txt"  in  the  DAV  directory  and  press  the  "delete" 

key. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

rm  upload2 . txt 

Test  A7  ensures  that  directories  can  be  created  via  the  WebDAV  client. 

Graphical  Clients: 

Create  a  new  directory  named  "test"  in  the  DAV  directory. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

mkdir  test2 

Test  A8  ensures  that  directories  can  be  traversed  via  the  WebDAV  client. 
Graphical  Clients: 

Double  click  on  the  directory  "test"  in  the  DAV  directory. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

cd  test2 

Test  A9  ensures  that  directories  can  be  deleted  via  the  WebDAV  client. 

Graphical  Clients: 

Select  the  directory  "test"  in  the  DAV  directory  and  press  the  "delete"  key. 
Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 
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rmcol  test2 


Test  A10  ensures  that  no  unrecoverable  errors  occur  when  attempting  to  read  a 
file  that  does  not  exist. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

cat  ifile 

Test  A1 1  ensures  that  no  unrecoverable  errors  occur  when  attempting  to  delete  a 
file  that  does  not  exist. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

rm  ifile 

Test  A12  ensures  that  no  unrecoverable  errors  occur  when  attempting  to  lock  a 
file  that  does  not  exist. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

lock  ifile 
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Test  A13  ensures  that  no  unrecoverable  errors  occur  when  attempting  to  unlock  a 
file  that  does  not  exist. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

unlock  ifile 

Test  A 14  ensures  that  no  unrecoverable  errors  occur  when  attempting  to  delete  a 
directory  that  does  not  exist. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  in  the  DAV  directory  with  Cadaver: 

rmcol  idir 

B.  SINGLE  LEVEL  SECURITY  TEST  PROCEDURES 

These  tests  are  to  be  performed  on  the  single  level  XTS  installation  type  described 
in  Appendix  A.  All  of  these  tests  assume  that  the  file  "readme.txt"  exists  on  the 
WebDAV  server  in  the  root  DAV  directory  as  well  as  in  all  of  the  subdirectories  (i.e.  the 
directories  named  for  their  security  levels),  and  that  "readme.txt'  and  "upload.txt"  exists 
on  the  desktop  of  the  client  system  used  for  testing.  Each  of  these  files  should  contain 
some  uniquely  identifying  text  to  ensure  that  operations  were  indeed  successful.  The 
expected  results  of  each  of  these  tests  are  given  inline  with  the  test  procedure.  All  of 
these  tests  are  performed  at  the  level  sll:H3. 

Test  B1  ensures  that  a  user  is  not  able  to  read  data  from  a  secrecy  level  higher 
than  the  level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 
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Navigate  to  the  directory  named  “sl2il3”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sl2il3 

Test  B2  ensures  that  a  user  is  able  to  read  data  from  a  secrecy  level  lower  than  the 
level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Navigate  to  the  directory  named  “slOiB”. 

Open  the  file  named  “readme. txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sl0il3 
cat  readme . txt 

Test  B3  ensures  that  a  user  is  able  to  read  data  from  a  secrecy  level  equal  to  the 
level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Navigate  to  the  directory  named  “sllil3”. 

Open  the  file  named  “readme. txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sllil3 
cat  readme . txt 

Test  B4  ensures  that  a  user  is  not  able  to  write  data  to  a  secrecy  level  higher  than 
the  level  of  the  currently  established  session.  This  operation  should  fail. 
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Graphical  Clients: 


Drag  the  file  “upload.txt”  from  the  desktop  to  the  directory  “sl2il3”. 
Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sl2il3 

Test  B  5  ensures  that  a  user  is  able  to  write  data  to  a  secrecy  level  lower  than  the 
level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Drag  the  file  “upload.txt”  from  the  desktop  to  the  directory  “slOiB”. 
Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sl0il3 

Test  B6  ensures  that  a  user  is  not  able  to  write  data  to  a  secrecy  level  equal  to  the 
level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 

Drag  the  file  “upload.txt”  from  the  desktop  to  the  directory  “sllil3”. 
Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  sllil3 

edit  upload2.txt 

Add  some  arbitrary  text  to  the  file  and  save  it. 

C.  MULTILEVEL  SECURITY  TEST  PROCEDURES 

These  tests  are  to  be  performed  on  all  the  multilevel  XTS  installation  type 
described  in  Appendix  A.  All  of  these  tests  assume  that  the  file  "readme.txt"  exists  on  the 
WebDAV  server  in  the  root  DAV  directory  as  well  as  in  all  of  the  subdirectories  of  the 
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“public”  directory  (i.e.  the  directories  named  for  their  security  levels),  that  the  files 
“adminread.txt”  (with  the  owner  set  to  the  “admin”  user  and  the  permissions  set  so  that 
only  the  “admin”  user  can  read  the  file)  and  “adminwrite.txt”  (with  the  owner  set  to  the 
“admin”  user  and  the  pennissions  set  so  that  only  the  “admin”  user  can  write  but  all  users 
can  read  the  file)  exist  in  the  subdirectories  of  the  “public”  directory  and  that  "readme.txf 
and  "upload.txt"  exists  on  the  desktop  of  the  client  system  used  for  testing.  Each  of  these 
files  should  contain  some  uniquely  identifying  text  to  ensure  that  operations  were  indeed 
successful.  The  expected  results  of  each  of  these  tests  are  given  inline  with  the  test 
procedure.  All  of  these  test  procedures  are  written  with  the  assumed  session  level  of 
sll:i/3  and  should  be  modified  appropriately  for  other  session  levels.  The  session  must  be 
established  as  the  demo  user. 

Due  to  an  unresolved  error,  the  contents  of  the  “public”  directory  cannot  be  listed. 
In  order  to  navigate  to  the  subdirectories  of  the  “public”  directory  via  one  of  the  graphical 
clients,  it  is  necessary  to  go  straight  to  that  directory  by  name,  “dav/public/sllil3”  for 
example.  Instructions  for  accessing  DAV  directories  by  name  are  found  in  Section  G  of 
Appendix  A. 

Tests  Cl  through  C3  ensure  that  a  user  is  not  able  to  read  data  from  a  secrecy 
level  higher  than  the  level  of  the  currently  established  session.  This  operation  should  fail 
as  the  higher  level  directory  is  inaccessible. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sl2il3”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  public/sl2il3 

Tests  C4  through  C6  ensure  that  a  user  is  able  to  read  data  from  a  secrecy  level 
lower  than  the  level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sl0il3”. 
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Open  the  file  “readme.txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  public/sl0il3 
cat  readme . txt 

Tests  C7  through  C9  ensure  that  a  user  is  able  to  read  data  from  a  secrecy  level 
equal  to  the  level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sllil3”. 

Open  the  file  “readme.txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  public/sllil3 
cat  readme . txt 

Tests  CIO  through  C12  ensure  that  a  user  is  not  able  to  write  data  to  a  secrecy 
level  higher  than  the  level  of  the  currently  established  session.  This  operation  should  fail 
as  the  higher  level  directory  is  inaccessible. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sl2il3”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  public/sl2il3 

Tests  C13  through  C15  ensure  that  a  user  is  not  able  to  write  data  to  a  secrecy 
level  lower  than  the  level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 
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Go  to  the  directory  named  “dav/public/sl0il3”. 

Drag  the  file  “upload.txt”  from  the  desktop  to  the  directory  “slOiB”. 
Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 

cd  public/sl0il3 
edit  upload2.txt 

Add  some  arbitrary  text  to  the  file  and  save  it. 

Tests  C16  through  C18  ensure  that  a  user  is  able  to  write  data  to  a  secrecy  level 
equal  to  the  level  of  the  currently  established  session.  This  operation  should  succeed. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sllil3”. 

Drag  the  file  “upload.txt”  from  the  desktop  to  the  directory  “slliB”. 
Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 


cd  public/sllil3 
edit  upload2.txt 


Add  some  arbitrary  text  to  the  file  and  save  it. 

Test  C19  ensures  that  a  user  is  not  able  to  read  data  from  a  file  that  is  owned  by 
another  user,  has  permissions  set  to  allow  only  the  owner  to  read  and  has  a  secrecy  level 
lower  than  the  level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sl0il3”. 

Open  the  file  named  “adminread.txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAV  directory  with  Cadaver: 
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cd  public/sl0il3 
cat  adminread.txt 


Test  C20  ensures  that  a  user  is  not  able  to  read  data  from  a  file  that  is  owned  by 
another  user,  has  permissions  set  to  allow  only  the  owner  to  read  and  has  a  secrecy  level 
equal  to  the  level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sllil3”. 

Open  the  file  named  “adminread.txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAY  directory  with  Cadaver: 


cd  public/sllil3 
cat  adminread.txt 


Test  C21  ensures  that  a  user  is  not  able  to  write  data  to  a  file  that  is  owned  by 
another  user,  has  permissions  set  to  allow  only  the  owner  to  write  and  has  a  secrecy  level 
equal  to  the  level  of  the  currently  established  session.  This  operation  should  fail. 

Graphical  Clients: 

Go  to  the  directory  named  “dav/public/sllil3”. 

Edit  the  file  named  “adminwrite.txt”. 

Cadaver: 

Issue  the  following  commands  in  the  DAY  directory  with  Cadaver: 


cd  public/sllil3 
edit  adminwrite.txt 


Add  some  arbitrary  text  to  the  file  and  save  it. 

Test  C22  ensures  that  multiple  users  are  not  able  to  lock  the  same  file 
simultaneously.  This  operation  should  fail. 

Graphical  Clients: 
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This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  with  the  first  client  in  the  DAV  directory 
with  Cadaver: 


cd  public/sllil3 
lock  readme.txt 


Issue  the  following  command  with  the  second  client  in  the  DAV  directory 
with  Cadaver: 


cd  public/sllil3 
lock  readme.txt 


Test  C23  ensures  that  a  user  is  not  able  to  write  to  a  file  that  has  been  locked  by 
another  user.  This  operation  should  fail. 

Graphical  Clients: 

This  test  is  not  applicable  for  a  graphical  client. 

Cadaver: 

Issue  the  following  command  with  the  first  client  in  the  DAV  directory 
with  Cadaver: 


cd  public/sllil3 
lock  readme.txt 


Issue  the  following  command  with  the  second  client  in  the  DAV  directory 
with  Cadaver: 


cd  public/sllil3 
edit  readme.txt 
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